Secure stacking setup

ABSTRACT

A method of configuring a stack includes: connecting stacking ports of a plurality of stackable devices using one or more stacking links; connecting a user console to a first one of the stackable devices; transmitting a stack setup command from the user console to the first stackable device; and establishing a stack in response to the stack setup command. The stack is established by initiating a discovery process with the first stackable device in response to the stack setup command, wherein the first stackable device requests and receives identifying information from the stackable devices over the stacking links during the discovery process. The topology of the stackable devices is displayed with the user console in response to the identifying information. The stackable devices are authenticated during the discovery process such that the stack setup is secure. The first stackable device becomes the active controller of the stack by default.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of, and claims benefit of,application Ser. No. 12/419,241 filed Apr. 6, 2009, entitled “SecureStacking Setup”, which is hereby incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to an improved method for configuring astack from a plurality of stackable network switches.

RELATED ART

Local area networks (LANs) may be implemented using a chassis-basedsystem, which includes a fixed chassis that supports a common backplane(i.e., a hardwired circuit board). The fixed chassis includes aplurality of slots for receiving and supporting a plurality of networkswitches (blades). When inserted into the slots in the chassis,connectors on the network switches engage with corresponding connectorsin the backplane, whereby electrical connections are formed between thenetwork switches and the backplane. The backplane provides electricalconnections between the connected network switches, and allow theplurality of network switches to be operated as a single managementunit. A slot number is assigned to each connector in the backplane inorder to identify the placement of each network switch within thebackplane. The slot numbers are fixed, and cannot be modified orassigned by the user of the chassis-based system. The hardwired natureof the backplane and the fixed slot numbers cause the configuration ofthe chassis-based system to be inflexible. Another disadvantage of thechassis-based system is the relatively large initial cost associatedwith purchasing the chassis/backplane.

An alternate system of connecting a plurality of network switches into asingle management unit is a stackable switch system. A stackable switchsystem does not use a fixed chassis or a backplane. Rather, a stackableswitch system includes a plurality of network switches that areconnected by cables that extend between dedicated stacking ports of thenetwork switches. These cables effectively replace the backplane of thechassis-based system. In a stackable switch system, the network switchesmay be connected in various topologies by re-arranging the cables.However, each of the network switches connected in a stackable switchsystem must be initially configured by connecting a user console to auser interface of the network switch (through a cable), and thenaccessing a command line interface (CLI) within the network switch.Because the user console must be individually connected to each of thenetwork switches, the configuration process is cumbersome. Moreover, theuser does not have an efficient way to assign the master role to anyparticular network switch in the stackable switch system. In addition,the user must individually access multiple CLIs (in the differentnetwork switches) to renumber the network switches included in thestack. Moreover, the user is not presented with an overall view of theconfigured stack.

It would therefore be desirable to have a manner of configuring a stack,which overcomes the above-described deficiencies.

SUMMARY

Accordingly, the present invention provides an improved method forestablishing a stack using a plurality of stackable network switches(hereinafter referred to as stackable devices). The stackable devicesare initially connected by a plurality of stacking links (cables),wherein each stacking link joins a stacking port of one stackable deviceto a stacking port of another stackable device. The stacking links mayjoin the stackable devices in a ring topology or a linear topology. Auser console is connected to a user interface of one of the stackabledevices. By default, the stackable device connected to the user consoleinitially becomes the active controller (master) of the stack. A securestack setup command is transmitted from the user console to theconnected stackable device (hereinafter, ‘the first stackable device).The first stackable device initiates a discovery process in response tothe secure stack setup command, wherein the first stackable devicerequests and receives identifying information from the other stackabledevices over the stacking links. Authentication of the stackable devicesis performed during the discovery process, thereby preventingunauthorized devices from joining the stack. Any passwords required bythe stackable devices may be entered via the user console, which remainsconnected to the first stackable device. The user console displays atopology of the stackable devices in response to the identifyinginformation gathered during the discovery process. In one embodiment,the topology identifies the stackable devices upstream and downstreamfrom the first stackable device, and the number of hops from the firststackable device to the other stackable devices. The user console may beused to modify the topology of the stackable devices. The user consolemay also be used to select stack ID values for the various stackabledevices. In this manner, the present invention provides a simple andflexible method for configuring a stack, wherein the stack configurationcan be easily viewed by the user.

The present invention will be more fully understood in view of thefollowing description and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a stack that includes three stackabledevices, which are configured in a ring topology in accordance with oneembodiment of the present invention.

FIG. 2 is a block diagram illustrating relevant fields of discoveryprotocol request packets used to set up the stack of FIG. 1 inaccordance with one embodiment of the present invention.

FIG. 3 is a block diagram of a stack that includes four stackabledevices, which are configured in a linear topology in accordance withone embodiment of the present invention.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of a stack 100 that includes three stackabledevices (e.g., network switches) ST1, ST2 and ST3, which are configuredin a ring topology in accordance with one embodiment of the presentinvention. As described herein, a ‘stack’ is a group of stackabledevices that are connected to operate as a single management unit havinga single internet protocol (IP) address. Although stack 100 includesthree stackable devices ST1-ST3, in the embodiments described herein, astack may include up to eight stackable devices. In yet otherembodiments, a stack may be limited to another number of stackabledevices.

Stackable devices ST1, ST2 and ST3 include data port sets 101, 102 and103, respectively, direct serial (console) ports 111, 112 and 113,respectively, LED displays 121, 122 and 123, respectively, command lineinterface (CLI) logic 131, 132 and 133, respectively, processors 141,142 and 143, respectively, memory blocks 151, 152 and 153, respectively,and stacking ports SP_(1U)-SP_(1D), SP_(2U)-SP_(2D) and SP_(3U)-SP_(3D),respectively. In general, memory blocks 151-153 store computerexecutable instructions that, when executed by the correspondingprocessors 141-143, cause the stackable devices ST1-ST3 to operate inthe manner described in more detail below. Memory blocks 151-153 alsostore identifying information specific to the associated stackabledevices ST1-ST3.

In the described embodiments, each of the data port sets 101-103includes a plurality of data ports (e.g., 10/100/1000 Ethernet ports),which are used to connect to network devices (not shown) to the stack100. These network devices can include, for example, computing resourcessuch as workstations, servers, printers and storage devices. Data portsets 101-103 are well known to those of ordinary skill in the art. Ingeneral, stack 100 controls the routing of data (packets/frames) betweennetwork devices coupled to different stackable devices ST1-ST3.

The command line interface (CLI) logic within each stackable device canbe accessed through the corresponding direct serial port, or through oneof the data ports of the corresponding stackable device, in a mannerknown to those of ordinary skill in the art. In accordance with thedescribed embodiments of the present invention, a user console 150 isconfigured to access CLI logic 131 in stackable device ST1 throughdirect serial port 111 or through one of the ports of the data port set101. As described in more detail below, user console 150 controls thesetup of stack 100 through CLI logic 131 (and the correspondingprocessor 141). Only one user console 150 is required to complete thesetup of stack 100. Advantageously, this user console 150 only needs tobe connected to a single stackable device (e.g., stackable device ST1)to complete the setup of stack 100.

By default, the stackable device coupled to user console 150 during thesetup of stack 100 initially becomes the master, or active controller,of stack 100. Thus, in the described embodiments, stackable device ST1becomes the active controller of stack 100. Stackable device ST1, as theactive controller, manages the entire stack 100.

In the embodiments described herein, each of the stackable devicesST1-ST3 includes two high-bandwidth (e.g., 10 G) stacking ports. Each ofthe stackable devices ST1-ST3 includes one stacking port designated asan upstream stacking port (and labeled with the subscript ‘U’), and onestacking port designated as a downstream stacking port (and labeled withthe subscript ‘D’). Thus, stacking ports SP_(1U), SP_(2U) and SP_(3U)are upstream stacking ports, and stacking ports SP_(1D), SP_(2D) andSP_(3D) are downstream stacking ports. The upstream stacking portsSP_(1U), SP_(2U) and SP_(3U) are coupled to the downstream stackingports SP_(2D), SP_(3D) and SP_(1D), respectively, by stacking links(cables) SL₁₂, SL₂₃ and SL₁₃, respectively. Each stacking link is apoint-to-point link that allows the bi-directional transfer of packetsbetween the stacking ports joined by the stacking link.

The setup of stack 100 will now be described in more detail. Stackabledevices ST1-ST3 are initially cabled in a linear or ring topology,connecting only those stackable devices that will be active in the stack100. In the embodiment of FIG. 1, the stack 100 is cabled in a ringtopology. (A linear topology is described in more detail below inconnection with the stack 300 of FIG. 3.) Stackable devices ST1-ST3 arethen powered on, and the user console 150 is connected to the intendedactive controller, which in the present example, is stackable deviceST1.

The user enters a ‘stack enable’ command on the user console 150. This‘stack enable’ command is transmitted from user console 150 to CLI logic131 of stackable device ST1. In response, processor 141 enablesstackable device ST1 to operate as a member of a stack. Advantageously,the ‘stack enable’ command does not need to be individually issued toeach of the other stackable devices ST2-ST3 of stack 100.

The user then enters a ‘stack secure setup’ command on the user console150. This command is transmitted from user console 150 to the CLI logic131 of the stackable device ST1. As described in more detail below, theentire stack 100 is configured in response to the ‘stack secure-setup’command. The ‘stack secure setup’ command received by CLI logic 131causes processor 141 to execute a set of computer executableinstructions stored by memory 151, thereby causing processor 141 toimplement a discovery process in both the upstream and downstreamdirections, starting from stackable device ST1. The discovery processproduces a list of upstream and downstream stackable devices that areavailable to join the stack 100.

Upon receiving the ‘stack secure setup’ command, processor 141 assigns apriority value to stackable device ST1, wherein the assigned priorityvalue helps to ensure that stackable device ST1 will initially berecognized as the active controller. In the described examples,stackable device ST1 is initially assigned a priority value of ‘128’. Asdescribed in more detail below, the assigned priority values of theother stackable devices capable of joining the stack (e.g., stackabledevices ST2-ST3) will eventually be learned by stackable device ST1. Ifstackable device ST1 determines that any of the other stackable deviceshas an assigned priority value greater than ‘128’, then stackable deviceST1 will issue a command that changes the assigned priority values ofthese stackable devices to ‘118’ (or another value less than ‘128’). Asa result, stackable device ST1 will initially have the highest assignedpriority, such that stackable device ST1 initially becomes the activecontroller of the stack 100.

The discovery process implements discovery protocol packets, which areexchanged by the various stackable devices ST1-ST3 in a manner describedin more detail below. In accordance with one embodiment of the presentinvention, these discovery protocol packets are used to convey severaldifferent messages, including: a ‘hello’ message, an ‘authenticationrequest’ message, an ‘authentication response’ message, an‘authentication successful’ message and an ‘authentication failed’message.

FIG. 2 is a block diagram that illustrates the relevant fields of thevarious messages of the discovery protocol, in accordance with oneembodiment of the present invention.

The discovery process will now be described in more detail. Uponreceiving the ‘stack secure setup’ command, a stackable device (i.e.,active controller) will transmit a ‘hello’ message on each of thestacking ports (upstream and downstream) of the stackable device. Each‘hello’ message transmitted from the originating stackable device willreach a stacking port of a connected stackable device at 1 hop. Eachstackable device located at 1 hop responds to the received ‘hello’message by performing an authentication process, which is described inmore detail below. In general, the authentication process involves thetransmission of an ‘authentication request’ message from the stackabledevice located at 1 hop, and the return of an ‘authentication response’message to the stackable device located at 1 hop. If the authenticationprocess is successful, the stackable device located at 1 hop transmitsan ‘authentication successful’ message to the originating stackabledevice, wherein this message provides information identifying thestackable device located at 1 hop. If the authentication process isunsuccessful, the stackable device located at 1 hop transmits an‘authentication failed’ message to the originating stackable device.

If the authentication process was successful for a stackable devicelocated at 1 hop, then this stackable device forwards the received‘hello’ message to the neighboring stackable device (if any) located at2 hops. The stackable device located at 2 hops performs anauthentication process by exchanging ‘authentication request’ and‘authentication response’ messages with the stackable device located at1 hop. Advantageously, this authentication process does not require theinvolvement of the originating stackable device (active controller). Ifthis authentication process is successful, the stackable device locatedat 2 hop transmits an ‘authentication successful’ message back to theoriginating stackable device (via the stackable device located at 1hop), wherein this message provides information identifying thestackable device located at 2 hop.

Note that if the authentication process was unsuccessful for thestackable device located at 1 hop, then this stackable device does notforward the ‘hello’ message (effectively preventing the discovery of aneighboring stackable device through the stackable device located at 1hop).

This mechanism continues recursively until each of the ‘hello’ messages(upstream and downstream) is forwarded up to N times, wherein N is equalto the maximum stack size minus one. In the described examples, themaximum stack size is eight, so each of the ‘hello’ messages can beforwarded up to seven times from the originating stackable switch. As aresult, the discovery process can discover up to seven upstreamstackable devices and up to seven downstream stackable devices, inaddition to the originating stackable device. Note that if the stack hasa ring topology that includes eight stackable devices, the sevendiscovered upstream stackable devices will be identical to the sevendiscovered downstream stackable devices. However, if the stack has alinear topology, then up to fourteen different stackable devices may bediscovered in addition to the originating stackable device. In thiscase, the user must select no more than eight of these stackable devicesto form the stack. As described in more detail below, the identifyinginformation associated with each of the discovered stackable devices isdisplayed to the user on the user console 150, thereby enabling the userto select the desired stack members/topology.

The ‘stack secure setup’ command will now be described in more detail inconnection with the stackable devices ST1-ST3 of FIG. 1. Upon receivingthe ‘stack secure setup’ command via CLI logic 131, processor 141 ofstackable device ST1 transmits a ‘hello’ message HEL_(1U) on upstreamstacking port SP_(1U), and a ‘hello’ message HEL_(1D) on downstreamstacking port SP_(1D).

FIG. 2 illustrates the relevant fields of a ‘hello’ message 200, an‘authentication request’ message 210, an ‘authentication response’message 220, an ‘authentication successful’ message 230 and an‘authentication failed’ message 240.

Each ‘hello’ message 200 includes a message-type field 201, a session-idfield 202, a unit-id field 203, a protocol revision field 204 and amaximum stack size field 205. The message-type field 201 identifies theassociated discovery protocol packet as a hello message. The purpose ofthe ‘hello’ message is to request information from the neighboringstackable device. The session-id field 202 identifies the discoveryprocess currently being implemented. The unit-id field 203 includes anID value that identifies the stackable device that originates the‘hello’ message (i.e., the stackable device connected to the userconsole 150). In the described examples, the unit-id field 203 of the‘hello’ messages HEL_(1U) and HEL_(1D) will identify stackable deviceST1. This unit-id field 203 may include, for example, the model numberand/or MAC address of stackable device ST1. In the described examples,stackable device ST1 has a model number of ‘FLS648’ and a MAC address of‘00e0.52ab.cd00’. The stackable device ST1 identified by the unit-idfield 203 is initially configured as the active controller of the stack100. The protocol revision field 204 includes information thatidentifies the current revision of the discovery protocol being used.The maximum stack size field 205 includes a value that identifies thenumber of times that the ‘hello’ message can be forwarded. In thedescribed examples, the maximum stack size field 205 is initiallyselected to have a value of ‘7’, such that the corresponding ‘hello’message can be forwarded up to seven times in either the upstream ordownstream direction. As will become apparent in view of the followingdescription, the maximum number of stackable devices in the stack islimited to the initial value stored in the maximum stack size field 205,plus one.

The ‘hello’ message HEL_(1U) transmitted on stacking port SP_(1U)reaches the stacking port SP_(2D) of stackable device ST2 at 1 hop viastacking link SL₁₂. Similarly, the ‘hello’ message HEL_(1D) transmittedon stacking port SP_(1D) reaches the stacking port SP_(3U) of stackabledevice ST3 at 1 hop via stacking link SL₁₃.

Upon receiving the ‘hello’ message HEL_(1U) on stacking port SP_(2D),stackable device ST2 determines whether its associated protocol revisioninformation matches the protocol revision information included in theprotocol revision field 204 of the received ‘hello’ message HEL_(1U).Stackable device ST2 may decide to discontinue the discovery process ifa match is not detected. In this case, stackable device ST2 returns an‘authentication fail’ message FAIL_(2D) to stackable device ST1. Each‘authentication failed’ message 240 includes a message-type field 241,which indicates that the authentication process was unsuccessful. Ifstackable device ST2 returns the ‘authentication failed’ messageFAIL_(2D) to stackable device ST1, then stackable device ST2 will not beallowed to join the stack 100. In addition, stackable device ST2 willnot forward the received ‘hello’ message HEL_(1U), thereby preventingthe discovery of upstream stackable devices through stackable deviceST2. Stackable device ST3 performs similar operations in response to the‘hello’ message HEL_(1D) received on stacking port SP_(3U). The protocolrevision information ensures that all members of a stack are configuredto implement the same protocol. In the described examples, it is assumedthat all of the stackable devices ST1-ST3 implement the same protocolrevision.

Thus, upon receiving the ‘hello’ message HEL_(1U) on stacking portSP_(2D), stackable device ST2 initiates an authentication process,wherein stackable device ST2 determines whether the stackable device ST1that transmitted the ‘hello’ message HEL_(1U) is an authentic device(i.e., a stackable device that should be allowed to join a stack thatincludes stackable device ST2). Similarly, upon receiving the ‘hello’message HEL_(1D) on stacking port SP_(3U), stackable device ST3initiates an identical authentication process.

To initiate the authentication process, a stackable device transmits an‘authentication request’ message to the stacking link on which thecorresponding ‘hello’ message was received. Thus, stackable device ST2transmits an ‘authentication request’ message REQ_(2D) to stackabledevice ST1 via stacking link SL₁₂. Similarly, stackable device ST3transmits an ‘authentication request’ message REQ_(3U) to stackabledevice ST1 via stacking link SL₁₃. Each ‘authentication request’ message210 is a discovery protocol packet that includes message-type field 211and key field 212 (FIG. 2). The message-type field 211 stores a valuethat identifies the associated discovery protocol packet as an‘authentication request’ message. The key field 212 stores a key valuethat is to be decoded by the stackable device receiving the‘authentication request’ message. In the present example,‘authentication request’ message REQ_(2D) includes a first key valueKEY₁, and ‘authentication request’ message includes a second key valueKEY₂.

In response to receiving an ‘authentication request’ message, astackable device will generate a decoded key value in response to thekey value included in the ‘authentication request’ message. Thus,stackable device ST1 generates a first decoded key value DKEY₁ inresponse to the key value KEY₁ included in the received ‘authenticationrequest’ message REQ_(2D). Stackable device ST1 also generates a seconddecoded key value DKEY₂ in response to the key value KEY₂ included inthe received ‘authentication request’ message REQ_(3U).

Stackable device ST1 then returns the decoded key values to thestackable devices that originated the ‘authentication request’ messages.More specifically, stackable device ST1 generates ‘authenticationresponse’ messages REP_(1U) and REP_(1D), which are transmitted tostackable devices ST2 and ST3, respectively. Each ‘authenticationresponse’ message 220 is a discovery protocol packet that includesmessage-type field 221, key field 222 and key-decode field 223 (FIG. 2).The message-type field 221 stores a value that identifies the associateddiscovery protocol packet as an ‘authentication response’ message. Thekey field 222 stores the key value that was originally received in thecorresponding ‘authentication request’ message. The key-decode field 223includes the decoded key value that was generated in response to the keyvalue of key field 222. Thus, stackable device ST1 provides an‘authentication response’ message REP_(1U) to stackable device ST2,wherein this message REP_(1U) includes the key value KEY₁ of the‘authentication request’ message REQ_(2D) and the corresponding decodedkey value DKEY₁. Stackable device ST1 also provides an ‘authenticationresponse message REP_(1D) to stackable device ST3, wherein this messageREP_(1D) includes the key value KEY₂ of the ‘authentication request’message REQ_(3U) and the corresponding decoded key value DKEY₂.

Upon receiving an ‘authentication response’ message, a stackable devicewill determine whether the authentication process was a success or afailure. To accomplish this, the stackable device receiving the‘authentication response’ message independently generates a decoded keyvalue in response to the original key value. For example, upon receivingthe authentication response message REP_(1U), stackable device ST2independently generates a decoded key value DKEY₁′ in response to theoriginal key value KEY₁. If this independently generated decoded keyvalue DKEY₁′ matches the decoded key value DKEY₁ included in the‘authentication response’ message REP_(1U), then the authenticationprocess is successful. Otherwise, the authentication process has failed.Note that both stackable devices must implement the same key decodingalgorithm in order for the authentication process to be successful.Unauthorized stackable devices will not implement the same key decodingalgorithms as authentic stackable devices, thereby preventing theauthentication of unauthorized stackable devices.

If a stackable device determines that the authentication process hasfailed because the decoded key values do not match, then this stackabledevice returns an ‘authentication failed’ message to the neighboringstackable device that originally transmitted the ‘hello’ message. Forexample, upon determining that the authentication process has failed,stackable device ST2 will transmit an ‘authentication failed’ messageFAIL_(2D) to stackable device ST1.

Similarly, upon determining that the authentication process has failed,stackable device ST3 will transmit an ‘authentication failed’ messageFAIL_(3U) to stackable device ST1. In response to receiving theFAIL_(2D) message or the FAIL_(3U) message, stackable device ST1 willnot allow the corresponding stackable device ST2 or ST3 to join thestack. In addition, if the authentication process has failed within astackable device, then this stackable device will not forward thereceived ‘hello’ message. For example, if authentication fails withinstackable device ST2, then stackable device ST2 will not forward thereceived ‘hello’ message HEL_(1U) on its upstream stacking port SP_(2U),thereby preventing the discovery of upstream stackable devices throughstackable device ST2. Similarly, if authentication fails withinstackable device ST3, then stackable device ST3 will not forward thereceived ‘hello’ message HEL_(1D) on its downstream stacking portSP_(3D), thereby preventing the discovery of downstream stackabledevices through stackable device ST3. However, in the describedexamples, it is assumed that the authentication process is successful inboth of stackable devices ST2 and ST3.

A stackable device that determines that the authentication process wassuccessful returns an ‘authentication successful’ message to theneighboring stackable device that originally transmitted the ‘hello’message. For example, upon determining that the authentication processwas successful, stackable devices ST2 and ST3 transmit ‘authenticationsuccessful’ messages SUCC_(2D) and SUCC_(3U), respectively, to stackabledevice ST1.

In accordance with one embodiment, the successful authentication of astackable device will expire after a predetermined period (e.g. 1minute) of inactivity. Thus, the ‘authentication successful’ messagemust be sent before the predetermined period expires. In the case thatthe predetermined period expires, the ‘stack secure setup’ command mustbe reissued to allow the stackable device to join the stack.

Each ‘authentication successful’ message 230 is a discovery protocolpacket that includes message-type field 231, hop-count field 232,unit-type field 233, priority field 234, security type field 235,security information field 236 and unit-id field 237 (FIG. 2). Themessage-type field 231 stores a value that identifies the associateddiscovery protocol packet as an ‘authentication successful’ message. Thehop count field 232 indicates the number of hops that the‘authentication successful’ message has traveled. The stackable devicethat originally generates the ‘authentication successful’ message setsthe hop count field 232 to a value of ‘1’. Thus, when stackable deviceST1 receives the ‘authentication successful’ message SUCC_(2D) thatoriginates in stackable device ST2, or the ‘authentication successful’message SUCC_(3U) that originates in stackable device ST3, the hop countfield 232 will have a value of ‘1’. If a stackable device that is notthe active controller receives an ‘authentication successful’ message onone of its stacking ports, this stackable device will add ‘1’ to thevalue stored in the hop count field 232, and then forward the modified‘authentication successful’ message to its other stacking port. As aresult, when an ‘authentication successful’ message is received by theactive controller (i.e., stackable device ST1), the hop count field 232indicates the number of hops that exist between the stackable devicethat originated the ‘authentication successful’ message and the activecontroller. The value stored in the hop count field 232 is limited tothe value initially stored in the maximum stack size field 205 of‘hello’ message 200. (e.g., 7).

The unit type field 233 includes information that identifies the type(e.g., model number) of the stackable device that originally generatesthe ‘authentication successful’ message. In the described examples,stackable device ST2 has a unit type of ‘FLS624’ and stackable deviceST3 has a unit type of ‘FGS624’. Note that stack 100 may supportmultiple different unit types.

The priority field 234 includes a priority value that specifies anassigned priority of the stackable device that originally generates the‘authentication successful’ message. In the described examples, thestackable devices ST2 and ST3 have assigned priority values of ‘0’,although this is not necessary. As described above, if the assignedpriority values of the stackable devices ST2 and ST3 are greater thanthe assigned priority value of stackable device ST1 (active controller),the stackable devices ST2 and ST3 will be re-assigned lower priorityvalues.

The security type field 235 and the security information field 236support further authentication, which may be required by stackabledevices other than the active controller. The security type field 235identifies a ‘type’ of security information included in the securityinformation field 236. The security information field 236 includes theactual security information required to access the stackable device thatoriginates the ‘authentication successful’ message. For example, thesecurity type field 235 of ‘authentication successful’ message SUCC_(2D)may indicate that a password is required in order to access stackabledevice ST2. In this case, the security information field 236 of‘authentication successful’ message SUCC_(2D) includes the (encrypted)password required to access stackable device ST2. In response toreceiving the ‘authentication successful’ message SUCC_(2D), stackabledevice ST1 decrypts the encrypted password, and requests that the userenter the password required to access stackable device ST2 via the userconsole 150. If the user properly enters the required password, thenstackable device ST1 will allow the password-protected stackable deviceST2 to join the stack 100. However, if the user does not enter thecorrect password, stackable device ST1 will not allow stackable deviceST2 to join the stack 100. As described in more detail below, if onestackable device is not allowed to join the stack, this may preventother stackable devices from joining the stack. Advantageously, the userdoes not have to connect the user console 150 to stackable device ST2 inorder to enter the required password. As a result, the configuration ofthe stack 100 is simplified.

The unit-id field 237 includes a value, such as a MAC address, thatidentifies the stackable device that originates the ‘authenticationsuccessful’ message. In the described examples, the unit-id field 237 of‘authentication successful’ message SUCC_(2D) has a value of0012.f239.2d40 (the MAC address of stackable device ST2), and theunit-id field 237 of ‘authentication successful’ message SUCC_(3U) has avalue of 0012.f2d5.2100 (the MAC address of stackable device ST3).

Upon receiving the ‘authentication successful’ messages SUCC_(2D) andSUCC_(3U) (and receiving any required security information from theuser), the stackable device ST1 (active controller) stores theassociated information (i.e., hop-count, unit-type, priority, securitytype, security info and unit-id) in a connectivity database.

If a stackable device generates an ‘authentication successful’ messagein response to a ‘hello’ message received on a first stacking port ofthe stackable device, then this stackable device will determine whetherthe value stored in the maximum stack size field 205 of this received‘hello message’ has a positive value. If so, then this stackable devicewill decrement the value stored in the maximum stack size field 205 ofthis ‘hello’ message by one, and forward the modified ‘hello’ messageonto the second stacking port of the stackable device.

In the example of FIG. 1, stackable device ST2 determines that the valuestored in the maximum stack size field 205 of the received ‘hello’message HEL_(1U) has a positive value (i.e., ‘7’). In response,stackable device ST2 decrements this value by one, such that the maximumstack size field 205 of the ‘hello’ message HEL_(1U) stores a value of‘6’. Stackable device then forwards this modified ‘hello’ messageHEL_(1U) to stackable device ST3 (via stacking port SP_(2U), stackinglink SL₂₃ and stacking port SP_(3D)). In response, stackable device ST3performs initiates the authentication process described above, whereinstackable device ST3 transmits an ‘authentication request’ messageREQ_(3D) to stackable device ST2, stackable device ST2 returns an‘authentication response’ message RES_(2U) to stackable device ST3, andstackable device ST3 determines whether the authentication process wassuccessful or failed. If the authentication is successful, stackabledevice ST3 generates an ‘authentication successful’ message SUCC_(3D) inthe manner described above. This ‘authentication successful’ message istransmitted to stackable device ST2 (via stacking port SP_(3D), stackinglink SL₂₃ and stacking port SP_(2U)). Stackable device ST2 adds ‘1’ tothe hop count field 232 of this ‘authentication successful’ messageSUCC_(3D), such that this hop count field 232 is modified to have avalue of ‘2’. Stackable device ST2 then transmits the modified‘authentication successful’ message SUCC_(3D) to stackable device ST1(via stacking port SP_(2D), stacking link SL₁₂ and stacking portSP_(1U)). Note that the ‘authentication successful’ message received bystackable device ST1 properly indicates that stackable device ST3 is 2hops from stackable device ST1 in the upstream direction. Stackabledevice ST1 stores the information included in ‘authenticationsuccessful’ message SUCC_(3D) in the connectivity database.

If the authentication fails, then stackable device ST3 generates an‘authentication failed’ message FAIL_(3D) in the manner described above.This ‘authentication failed’ message is transmitted to stackable deviceST2 (via stacking port SP_(3D), stacking link SL₂₃ and stacking portSP_(2U)). In response, stackable device ST2 does not allow stackabledevice ST3 to join the stack 100 via stacking link SL₂₃.

In a similar manner, stackable device ST3 modifies the maximum stacksize field 205 of the ‘hello’ message HEL_(1D) to store a value of ‘6’,and then forwards this modified ‘hello’ message HEL_(1D) upstream tostackable device ST2 (via stacking port SP_(3D), stacking link SL₂₃ andstacking port SP_(2U)). In response, stackable device ST2 initiates theauthentication process described above, wherein stackable device ST2transmits an ‘authentication request’ message REQ_(2U) to stackabledevice ST3, stackable device ST3 returns an ‘authentication response’message REP_(3D) to stackable device ST2, and stackable device ST2determines whether the authentication process was successful or failed.If the authentication is successful, stackable device ST2 generates an‘authentication successful’ message SUCC_(2U) in the manner describedabove. This ‘authentication successful’ message SUCC_(2U) is transmittedto stackable device ST3 (via stacking port SP_(2U), stacking link SL₂₃and stacking port SP_(3D)). Stackable device ST3 adds ‘1’ to the hopcount field 232 of this ‘authentication successful’ message SUCC_(2U),such that this hop count field 232 is modified to have a value of ‘2’.Stackable device ST3 then transmits the modified ‘authenticationsuccessful’ message SUCC_(2U) to stackable device ST1 (via stacking portSP_(3D), stacking link SL₁₃ and stacking port SP_(1D)). Note that the‘authentication successful’ message SUCC_(2U) received by stackabledevice ST1 properly indicates that stackable device ST2 is 2 hops fromstackable device ST1 in the downstream direction. Stackable device ST1stores the information included in ‘authentication successful’ messageSUCC_(2U) in the connectivity database.

If the authentication fails, then stackable device ST2 generates an‘authentication failed’ message FAIL_(2U) in the manner described above.This ‘authentication failed’ message FAIL_(2U) is transmitted tostackable device ST3 (via stacking port SP_(2U), stacking link SL₂₃ andstacking port SP_(3D)). In response, stackable device ST3 does not allowstackable device ST2 to join the stack 100 via stacking link SL₂₃.

In the manner described above, the authentication process is performedbetween two neighboring stackable devices, and therefore does not alwaysrequire the participation of the active controller.

Continuing with the example of FIG. 1, it will be assumed that theauthentication processes performed between stackable devices ST2 and ST3are successful. In this case, stackable device ST3 determines that themaximum stack size field 205 of the received ‘hello’ message HEL_(1U)stores a positive value (i.e., ‘6’). In response, stackable device ST3decrements this value by one, such that the maximum stack size field 205of the ‘hello’ message HEL_(1U) stores a value of ‘5’. Stackable deviceST3 then forwards this modified ‘hello’ message HEL_(1U) to stackabledevice ST1 (via stacking port SP_(3U), stacking link SL₁₃ and stackingport SP_(1 D)).

Similarly, stackable device ST2 determines that the maximum stack sizefield 205 of the received ‘hello’ message HEL_(1D) stores a positivevalue (i.e., ‘6’). In response, stackable device ST2 decrements thisvalue by one, such that the maximum stack size field 205 of the ‘hello’message HEL_(1D) stores a value of ‘5’. Stackable device ST2 thenforwards this modified ‘hello’ message HEL_(1U) to stackable device ST1(via stacking port SP_(2D), stacking link SL₁₂ and stacking portSP_(1U)).

Upon receiving the ‘hello’ messages HEL_(1U) and HEL_(1D), stackabledevice ST1 determines that it originated these ‘hello’ messages HEL_(1U)and HEL_(1D) from the value stored in the unit-id field 203. Inresponse, stackable device ST1 determines that the stack 100 has a ringtopology, and modifies the connectivity database to reflect this fact.Note that if the stack 100 were connected in a linear topology,stackable device ST1 would not receive the ‘hello’ messages HEL_(1U) andHEL_(1D), as there would be no return path for these messages.

Note that after a ‘hello’ message has been forwarded seven times, themaximum stack size field 205 of this ‘hello’ message will have a valueof ‘0’. If a stackable device receives a ‘hello’ message with a maximumstack size field 205 having a value of ‘0’, this stackable device willneither respond to nor forward this ‘hello’ message, because it is notpossible that any stackable device receiving the ‘hello’ message couldbe added to the stack without exceeding the maximum stack size. Notethat if the maximum number of stackable devices (e.g., 8) are connectedin a ring topology, then the stackable device ST1 will receive ‘hello’messages HEL_(1U) and HEL_(1D) having maximum stack size fields 205 thatstore values of ‘0’. In this case, the stackable device ST1 may usethese received ‘hello’ messages HEL_(1U) and HEL_(1D) to determine thatthe stack is connected in a ring topology.

Note that if more than eight stackable devices are connected in a ring,or if more than eight stackable devices are connected upstream ordownstream of stackable device ST1 in a linear topology, then themaximum stack size field 205 of the forwarded ‘hello’ message(s) will bereduced to ‘0’ after being forwarded seven times.

In the manner described above, stackable device ST1 develops aconnectivity database for all possible members of the stack in responseto the ‘stack secure setup’ command. Stackable device ST1 presents thisconnectivity database to the user via user console 150. In accordancewith the embodiment illustrated by FIG. 1, the user console 150 displaysthe following information. Note that the possible members of the stackare presented in both the upstream and downstream directions, withrespect to stackable device ST1.

Display 1

Current Discovered Topology - RING Hop(s) Type MAC address AvailableUPSTREAM Units 1 FLS624 0012.f239.2d40 2 FGS624 0012.f2d5.2100 AvailableDOWNSTREAM Units 1 FGS624 0012.f2d5.2100 2 FLS624 0012.f239.2d40 Do youaccept the topology (RING) (y/n)?

Note that the user console 150 prompts the user to accept (or reject)the ring topology. If the user accepts the ring topology, then stackabledevice ST1 will assign stack ID values (Id) to each of the stackabledevices ST1-ST3, and cause the user console 150 to display the assignedstack ID values as follows.

Display 2

Selected Topology Active Id Type MAC address 1 FLS648 00e0.52ab.cd00CHop(s) Id Type MAC address Selected UPSTREAM Units 1 3 FLS6240012.f239.2d40 2 2 FGS624 0012.f2d5.2100 Selected DOWNSTREAM Units 1 2FGS624 012.f2d5.2100 2 3 FLS624 0012.f239.2d40 Do you accept the unitid's (y/n)?

Note that stackable device ST1, which is the active controller, isassigned a stack ID value of ‘1’. Stackable devices ST2 and ST3 areassigned stack ID values of ‘3’ and ‘2’, respectively. In oneembodiment, stackable device ST1 assigns consecutive stack ID values inthe upstream direction for a ring topology.

The user console 150 prompts the user to accept (or reject) the assignedstack ID values. If the user accepts the assigned stack ID values, thenthe secure setup of stack 100 is complete.

If the user rejects the assigned stack ID values, then stackable switchST1 asks the user (via user console 150) to assign the desired stack IDvalues, one by one, to the stackable devices ST1-ST3. The user canselect any number between 1 and the maximum allowed stack ID value(e.g., 8). A duplicate number for a stack ID value can't be selected asall the members of the stack need to have distinct stack ID values. Inone embodiment, the following is displayed on the user console 150,wherein the bold numbers represent the user's input required to changethe stack ID value of stackable device ST2 to ‘2’ and the stack ID valueof stackable device ST3 to ‘3’.

Display 3

Enter an unused id for the UPSTREAM FLS624 unit at 1 hop(s) 2 (1-8) [3]:Enter an unused id for the UPSTREAM FGS624 unit at 2 hop(s) 3 (1-8) [2]:

When the user is done assigning the desired stack ID values, the securesetup of stack 100 is complete.

Note that the user rejects the ring topology in response to the queryprovided in Display 1 above. In this case, the active controller ST1will prompt the user to select the desired topology from the upstreamand downstream devices in the connectivity database. In the example ofFIG. 1, user console 150 will display the following if the user rejectsthe ring topology.

Display 4

Do you accept the topology (RING) (y/n): n Hop(s) Type MAC addressAvailable UPSTREAM Units 1 FLS624 0012.f239.2d40 2 FGS624 0012.f2d5.2100Available DOWNSTREAM Units 1 FGS624 0012.f2d5.2100 2 FLS6240012.f239.2d40 Enter the number of desired UPSTREAM units (0-2)[0]: 1Enter the number of desired DOWNSTREAM units (0-2)[0]: 1

In the illustrated example, the user selects one upstream unit (i.e.,stackable device ST2) and one downstream unit (i.e., stackable deviceST3). However, the user could alternately select two upstream units andzero downstream units, two downstream units and zero upstream units, oneupstream unit and zero downstream units, or one downstream unit and zeroupstream units. In any of these alternatives, the stack will have alinear topology. In response to the entries illustrated by Display 4,the active controller ST1 will cause the following to be displayed byuser console 150.

Display 5

Selected topology: Active Id Type MAC address 1 FLS648 00e0.52ab.cd00Hop(s) Id Type MAC address Selected UPSTREAM units 1 2 FLS6240012.f239.2d40 Selected DOWNSTREAM units 1 3 FGS624 0012.f2d5.2100 Doyou accept the unit ID's (y/n):

The user can accept the unit ID's or modify the unit ID's in the mannerdescribed above in connection with Display 3.

The user can view the stack topology by entering a ‘show stack’ commandvia user console 150. The following information is shown by the userconsole 150 in response to the ‘show stack’ command. This exampleassumes that the user accepted the ring topology in Display 1 above, andalso accepted the automatically assigned stack ID values in Display 2above. Note that the stackable device ST1 has randomly assigned the roleof standby controller to stackable device ST2 in this example (as bothstackable devices ST2 and ST3 have the same priority of ‘0’).

Display 6

Alone: standalone, D: dynamic config, S: static config Id Type Role MACaddress Pri State Comment 1 S FLS648 active 00e0.52ab.cd00 128 localReady 2 S FGS624 standby 0012.f2d5.2100 0 remote Ready 3 S FLS624 member0012.f239.2d40 0 remote Ready

The priority of each of the stackable devices ST1-ST3 can be modified bya ‘priority’ command, which is entered via user console 150. Eachpriority command specifies the unit ID of the stackable device and thedesired priority value of the stackable device. The stackable devicehaving the highest assigned priority will become the active controllerof the stack, and the stackable device having the next highest assignedpriority will become the standby controller of the stack.

After the secure setup of stack 100 is complete, the user enters a‘write memory’ command via the user console 150. In response, stackabledevice ST1 initiates configuration synchronization, which copies theconfiguration database from stackable device ST1 to the rest of thestackable devices ST2-ST3 in the stack. At this time, stackable devicesST1, ST2 and ST3 display their assigned stack ID values (e.g., ‘1’, ‘3’and ‘2’, respectively) on their associated LED displays 121, 122 and123, respectively. As a result, the user can readily determine the stackID values assigned to stackable devices ST1-ST3, simply by looking atthe LED displays 121-123.

A synchronized copy of the startup configuration file of stackabledevice ST1 (i.e., the active controller) is also stored in stackabledevice ST2 (i.e., the standby controller), for use in the event thatstackable device ST1 fails. If stackable device ST1 fails, stackabledevice ST2 waits a default interval of 30 seconds, then takes over asthe active controller.

When the stack 100 is formed, the console function for each stack member(e.g. stackable devices ST2 and ST3) is automatically redirected to theactive controller (e.g., stackable device ST1). The active controllerhandles all stack management functions. If the user erroneously connectsthe user console 150 to a stack member that is not the activecontroller, the user is instructed to re-connect the user console 150 tothe active controller (e.g., the user console 150 may display a messagesuch as “reconnect user console to stack ID unit no. 1”).

The stack 100 is identified in an associated network by a single MACaddress (e.g., the MAC address of the active controller). If a newactive controller is elected, the MAC address of the new activecontroller becomes the MAC address for the entire stack 100.

A new stackable device can be added to stack 100 in the followingmanner. The stackable devices ST1-ST3 of stack 100 are powered down, andthe new stackable device is connected to the stack 100 in the desiredconfiguration, by connecting stacking links to the various stackingports in the manner described above. The secure setup process isperformed in the manner described above, whereby a stack topology isselected and stack ID values are assigned. During this process, theactive controller will reset the new stackable device. After the newstackable device boots and joins the stack, the user issues a ‘writememory’ command through the user console, thereby finalizing the newstack.

FIG. 3 is a block diagram of a stack 300 that includes the stackabledevices ST1, ST2, ST3 and ST4 configured in a linear topology inaccordance with one embodiment of the present invention. Because stack300 is similar to stack 100, similar elements in FIGS. 1 and 3 arelabeled with similar reference numbers. Thus, stack 300 includesstackable devices ST1, ST2 and ST3, stacking links SL₁₂ and SL₁₃, anduser console 150, which have been described above in connection withFIG. 1. The serial link SL₂₃ of stack 100 is eliminated in stack 300.Within stack 300, the stacking port SP_(2U) of stackable device ST2 iscoupled to the stacking port SP_(4D) of stackable device ST4 by stackinglink SL₂₄.

When the user issues the ‘stack secure setup’ command on user console150, stackable device ST1 transmits the ‘hello’ messages HEL_(1U) andHEL_(1D) on stacking ports SP_(1U) and SP_(1D), respectively, in themanner described above. In response, stackable devices ST2 and ST3initiate the authentication process in the manner described above. Inthe present example, it is assumed that the authentication process issuccessful and all necessary security information is entered properly.Note that stackable device ST3 does not forward the ‘hello’ messageHEL_(1D) to stacking port SP_(3D), because this stacking port SP_(3D) isnot connected to a stacking link.

Stackable device ST2 decrements the maximum stack size field 205 of the‘hello’ message HEL_(1U) by one, and then forwards this modified ‘hello’message HEL_(1U) to stackable device ST4 (via stacking port SP_(2U),stacking link SL₂₄ and stacking port SP_(4D)). In response, stackabledevice ST4 initiates the authentication process in the manner describedabove. In the present example, it is assumed that the authenticationprocess is successful. As a result, an ‘authentication successful’message SUCC_(4D) is transmitted from stackable device ST4 to stackabledevice ST1 (through stackable device ST2). In the present example, this‘authentication successful’ message SUCC_(4D) includes a hop count field232 having a value of ‘2’, a unit type field 233 having a value of‘FGS624’ (which is the model number of stackable device ST4), and aunit-id field 237 having a value of 0012.f2d2.2200 (which is the MACaddress of stackable device ST4). It is further assumed that allnecessary security information (if any) associated with stackable deviceST4 is entered properly.

After the above-described discovery process is complete, stackabledevice ST1 will present the following connectivity database to the uservia user console 150. Note that stackable device ST1 does not assume aring topology, because stackable device ST1 did not receive the ‘hello’messages HEL_(1U) and HEL_(1D), and different stackable devices areavailable in the upstream and downstream directions.

Display 7

Current Discovered Topology Hop(s) Type MAC address Available UPSTREAMUnits 1 FLS624 0012.f239.2d40 2 FGS624 0012.f2d2.2200 AvailableDOWNSTREAM Units 1 FGS624 0012.f2d5.2100 Enter the number of desiredUPSTREAM units [1-2]: 2 Enter the number of desired DOWNSTREAM units[0-1]: 1

Note that the user console 150 prompts the user to select the number ofupstream and downstream stackable devices to be included in the stack300. As indicated by the bold entries in Display 7 above, the userselects the upstream stackable devices ST2 and ST4, and the downstreamstackable device ST3 to join the stack 300 (although this is notnecessary). In response, stackable device ST1 assigns stack ID values(Id) to each of the stackable devices ST1-ST4, and causes the userconsole 150 to display the assigned stack ID values as follows.

Display 8

Selected Topology Active Id Type MAC address 1 FLS648 00e0.52ab.cd00Hop(s) Id Type MAC address Selected UPSTREAM Units 1 2 FLS6240012.f239.2d40 2 4 FGS624 0012.f2d2.2200 Selected DOWNSTREAM Units 1 3FGS624 012.f2d5.2100 Do you accept the unit id's (y/n)?

The user console 150 prompts the user to accept (or reject) the assignedstack ID values. If the user accepts the assigned stack ID values, thenthe secure setup of stack 100 is complete.

If the user rejects the assigned stack ID values, then stackable switchST1 asks the user (via user console 150) to assign the desired stack IDvalues, one by one, to the stackable devices ST1-ST3. The user canselect any number between 1 and the maximum allowed stack ID value(e.g., 8). A duplicate number for a stack ID value can't be selected asall the members of the stack need to have distinct stack ID values. Inone embodiment, the following is displayed on the user console 150,wherein the bold numbers represent the user's input required to changethe stack ID values of stackable devices ST2, ST3 and ST4 to ‘3’, ‘2’and ‘4’, respectively.

Display 9

Enter an unused id for the UPSTREAM FLS624 unit at 1 hop(s) 3 (1-8) [2]:Enter an unused id for the UPSTREAM FGS624 unit at 2 hop(s) 4 (1-8) [4]:Enter an unused id for the DOWNSTREAM FGS624 unit at 1 hop(s) 2 (1-8)[3]:

When the user is done assigning the desired stack ID values, the usermay issue the ‘show stack’ command to view the stack on user console150.

Display 10

Alone: standalone, D: dynamic config, S: static config Id Type Role MACaddress Pri State Comment 1 S FLS648 active 00e0.52ab.cd00 128 localReady 2 S FGS624 standby 0012.f2d5.2100 0 remote Ready 3 S FLS624 member0012.f239.2d40 0 remote Ready 4 S FGS624 member 0012.f2d2.2200 0 remoteReady

The user may then issue the ‘write memory’ command to store the stackconfiguration database in each of the stackable devices ST1-ST4.

Note that if stackable device ST2 required a password, and the user wasunable to provide this password, then stackable device ST2 would not beincluded in the connectivity database. In this case, stackable deviceST2 cannot be added to the stack 300. If a stackable device is removedfrom the connectivity database, all the stackable devices that can onlybe accessed through this stackable device are also removed from theconnectivity database. Thus, in the described example, stackable deviceST4 would not be included in the connectivity database, and would not beallowed to join the stack 300, if the user does not provide the passwordrequired by stackable device ST2.

Note that the user is unable to provide a password required by stackabledevice ST2 in the ring topology illustrated by FIG. 1, then stackabledevice ST2 would not be allowed to join the stack, thereby preventingthe formation of a stack having a ring topology. However, the user wouldbe presented the option of configuring a stack having a linear topology,which includes only stackable devices ST1 and ST3.

If a ‘hello’ message is received by a stackable device that is already amember of another stack (as indicated by the configuration databasestored by the stackable device), further discovery is terminated (i.e.,the stackable device belonging to another stack does not respond to thereceived ‘hello’ message, and does not forward the received ‘hello’message).

The present invention provides a unique way to manage a stack formed ofa plurality of stackable devices. Advantageously, the user doesn't haveto individually access each of the plurality of stackable devices inorder to configure the stack. Because the user can configure the stackthrough a single stackable device, significant time and effort is saved.

Moreover, the user can obtain a complete view of the stack by accessinga single stackable device. The user can thereby obtain a complete viewof switchable devices that are available to join the stack, and canselect which of the switchable devices join the stack.

In addition, the user can select the active controller and stacktopology by accessing a single stackable device. The single stackabledevice that is accessed automatically becomes the active controller ofthe stack, and hence no configuration is needed to select the activecontroller. Also the discovery process presents all the discoveredstackable devices in the network, and allows the user to select thetotal number of stackable devices in upstream and downstream directionsas well as the stack topology.

Although the present invention has been described in connection withvarious embodiments, it is understood that variations of theseembodiments would be obvious to one of ordinary skill in the art. Thus,the present invention is limited only by the following claims.

1. A stackable switching device, comprising: a plurality of ports; aninput port configured to receive input from a user console device; and aprocessor configured to receive a stack setup command from the userconsole device via the input port and, in response to receiving thestack setup command, to initiate discovery of other stackable switchingdevices; wherein the processor is further configured to cause topologyinformation to be displayed on the user console device and to receive anacknowledgement command from a user of the user console deviceindicative as to whether the user accepts or rejects at least a portionof the topology information.
 2. The stackable switching device of claim1 wherein, if a user accepts the topology via the user console device,the processor assigns stack identifier (ID) values to each of thestackable switching devices that form a stack.
 3. The stackableswitching device of claim 1 wherein the topology information caused tobe displayed includes an indication of each stackable switching devicein a stack and the stack identifier (ID) value assigned by the processorto each such stackable switching device.
 4. The stackable switchingdevice of claim 1 wherein the topology information includes stackidentifier (ID) values and wherein the processor prompts the user of theuser console device to accept or reject the ID values.
 5. The stackableswitching device of claim 4 wherein, if the user rejects the ID values,the processor is configured to receive a replacement stack ID value forat least one stack ID value included in the topology information.
 6. Thestackable switching device of claim 1 wherein the processor receives awrite memory command from the user console device and, in response, theprocessor initiates a configuration synchronization in which copies of aconfiguration database are copied to the other stackable switchingdevices.
 7. The stackable switching device of claim 6 further includinga display, and wherein the processor is configured to cause a stackidentifier (ID) value to be displayed on the display.
 8. The stackableswitching device of claim 1 wherein upon receiving the stack setupcommand, the processor assigns a priority value to the stackableswitching device, and the processor receives priority values for otherstackable switching devices, compares the other switching devices'priority values to the stackable switching device's own assignedpriority value and, if another stackable switching device has a priorityvalue that conflicts with the stackable switching device's own assignedpriority value, the stackable switching device issues a command tochange the conflicting priority value of such other stackable switchingdevice.
 9. A stackable switching device, comprising: a plurality ofports; an input port configured to receive input from a user consoledevice; and a processor configured to receive a stack setup command fromthe user console device via the input port and, in response to receivingthe stack setup command, to initiate discovery of other stackableswitching devices to generate topology information; wherein uponreceiving the stack setup command, the processor assigns a priorityvalue to the stackable switching device, and the processor receivespriority values for other stackable switching devices, compares theother switching devices' priority values to the stackable switchingdevice's own assigned priority value and, if another stackable switchingdevice has a priority value that conflicts with the stackable switchingdevice's own assigned priority value, the stackable switching deviceissues a command to change the conflicting priority value of such otherstackable switching device
 10. The stackable switching device of claim9, wherein the processor is further configured to cause the topologyinformation to be displayed on the user console device and to receive anacknowledgement command from a user of the user console deviceindicative as to whether the user accepts or rejects at least a portionof the topology information.
 11. The stackable switching device of claim10 wherein, if a user accepts the topology via the user console device,the processor assigns stack identifier (ID) values to each of thestackable switching devices that form a stack.
 12. The stackableswitching device of claim 9 wherein the topology information includes anindication of each stackable switching device in a stack and the stackidentifier (ID) value assigned by the processor to each such stackableswitching device.
 13. The stackable switching device of claim 9 whereinthe topology information includes stack identifier (ID) values andwherein the processor prompts the user of the user console device toaccept or reject the ID values.
 14. The stackable switching device ofclaim 13 wherein, if the user rejects the ID values, the processor isconfigured to receive a replacement stack ID value for at least onestack ID value included in the topology information.
 15. The stackableswitching device of claim 9 wherein the processor receives a writememory command from the user console device and, in response, theprocessor initiates a configuration synchronization in which copies of aconfiguration database are copied to the other stackable switchingdevices.
 16. The stackable switching device of claim 15 furtherincluding a display, and wherein the processor is configured to cause astack identifier (ID) value to be displayed on the display.
 17. A methodimplemented on a stackable switching device, comprising: receiving astack setup command; in response to receiving the stack setup command,initiating discovery of other stackable switching devices to generatetopology information; displaying the topology information; and receivingan acknowledgement command indicative as to whether a user accepts orrejects at least a portion of the topology information.
 18. The methodof claim 17 wherein the topology information includes an indication ofeach stackable switching device in a stack and the stack identifier (ID)value assigned to each such stackable switching device.
 19. The methodof claim 17 further receiving a write command and, in response,initiating a configuration synchronization by causing a configurationdatabase to be copied to the other stackable switching devices.
 20. Themethod of claim 17 further comprising: upon receiving the stack setupcommand, assigning a priority value to the stackable switching device;receiving priority values for other stackable switching devices;comparing the other switching devices' priority values to the stackableswitching device's own assigned priority value; and if another stackableswitching device has a priority value that conflicts with the stackableswitching device's own assigned priority value, issuing a command tochange the conflicting priority value of such other stackable switchingdevice.